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1. ID3 tag version 2.3.0 


1.1. Status of this document 


This document is an informal standard and replaces the id3v2.2.0 standard. The informal standard is released so that 
implementors could have a set standard before a formal standard is set. The formal standard will use another version 
or revision number if not identical to what is described in this document. The contents in this document may change 
for clarifications but never for added or altered functionality. 


Distribution of this document is unlimited. 


1.2. Abstract 


This document describes the ID3v2.3.0 standard, which is a more developed version of the ID3v2 informal standard 
(version [:id3v2-00: 2.2.0]), evolved from the ID3 tagging system. The ID3v2 offers a flexible way of storing 
information about an audio file within itself to determine its origin and contents. The information may be technical 
information, such as equalisation curves, as well as related meta information, such as title, performer, copyright etc. 
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2. Conventions in this document 


In the examples, text within "" is a text string exactly as it appears in a file. Numbers preceded with $ are hexadecimal 
and numbers preceded with % are binary. $xx is used to indicate a byte with unknown content. %x is used to indicate 
a bit with unknown content. The most significant bit (MSB) of a byte is called 'bit 7' and the least significant bit (LSB) 
is called 'bit 0". 


A tag is the whole tag described in this document. A frame is a block of information in the tag. The tag consists of a 
header, frames and optional padding. A field is a piece of information; one value, a string etc. A numeric string is a 
string that consists of the characters 0-9 only. 


3. ID3v2 overview 


The two biggest design goals were to be able to implement ID3v2 without disturbing old software too much and that 
ID3v2 should be as flexible and expandable as possible. 


The first criterion is met by the simple fact that the MPEG decoding software uses a syncsignal, embedded in the 
audiostream, to ‘lock on to' the audio. Since the ID3v2 tag doesn't contain a valid syncsignal, no software will attempt 
to play the tag. If, for any reason, coincidence make a syncsignal appear within the tag it will be taken care of by the 
‘unsynchronisation scheme’ described in section 5. 


The second criterion has made a more noticeable impact on the design of the ID3v2 tag. It is constructed as a 
container for several information blocks, called frames, whose format need not be known to the software that 
encounters them. At the start of every frame there is an identifier that explains the frames' format and content, and a 
size descriptor that allows software to skip unknown frames. 


If a total revision of the ID3v2 tag should be needed, there is a version number and a size descriptor in the ID3v2 
header. 


The ID3 tag described in this document is mainly targeted at files encoded with MPEG-1/2 layer |, MPEG-1/2 layer Il, 
MPEG-1/2 layer IIl and MPEG-2.5, but may work with other types of encoded audio. 


The bitorder in ID3v2 is most significant bit first (MSB). The byteorder in multibyte numbers is most significant byte 


first (e.g. $12345678 would be encoded $12 34 56 78). 


It is permitted to include padding after all the final frame (at the end of the ID3 tag), making the size of all the frames 
together smaller than the size given in the head of the tag. A possible purpose of this padding is to allow for adding a 
few additional frames or enlarge existing frames within the tag without having to rewrite the entire file. The value of 
the padding bytes must be $00. 


3.1. ID3v2 header 


The ID3v2 tag header, which should be the first information in the file, is 10 bytes as follows: 


ID3v2/file identifier WIE IDSs 

ID3v2 version $03 00 

ID3v2 flags sabc00000 
ID3v2 size Ml 2s BOK 


The first three bytes of the tag are always "ID3" to indicate that this is an ID3v2 tag, directly followed by the two 
version bytes. The first byte of ID3v2 version is it's major version, while the second byte is its revision number. In this 
case this is ID3v2.3.0. All revisions are backwards compatible while major versions are not. If software with ID3v2.2.0 
and below support should encounter version three or higher it should simply ignore the whole tag. Version and 
revision will never be $FF. 


The version is followed by one the ID3v2 flags field, of which currently only three flags are used. 
a - Unsynchronisation 


Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is used (see section 5 for details); a set bit 
indicates usage. 


b - Extended header 


The second bit (bit 6) indicates whether or not the header is followed by an extended header. The extended 
header is described in section 3.2. 


c - Experimental indicator 
The third bit (bit 5) should be used as an ‘experimental indicator’. This flag should always be set when the tag 
is in an experimental stage. 


All the other flags should be cleared. If one of these undefined flags are set that might mean that the tag is not 
readable for a parser that does not know the flags function. 


The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7) is set to zero in every byte, making 
a total of 28 bits. The zeroed bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01. 


The ID3v2 tag size is the size of the complete tag after unsychronisation, including padding, excluding the header but 
not excluding the extended header (total tag size - 10). Only 28 bits (representing up to 256MB) are used in the size 
description to avoid the introducuction of ‘false syncsignals'. 


An ID3v2 tag can be detected with the following pattern: 
SAS Ad 33 VAY Wy 8 we me ae Bm 


Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80. 


3.2. ID3v2 extended header 


The extended header contains information that is not vital to the correct parsing of the tag information, hence the 
extended header is optional. 


Extended header siz Seok Se BOK SOK 
Extended Flags SEGK Hox 
Size of padding Seek SOK RG SK 


Where the 'Extended header size’, currently 6 or 10 bytes, excludes itself. The 'Size of padding’ is simply the total tag 
size excluding the frames and the headers, in other words the padding. The extended header is considered separate 
from the header proper, and as such is subject to unsynchronisation. 


The extended flags are a secondary flag set which describes further attributes of the tag. These attributes are 
currently defined as follows 


%x0000000 00000000 


x - CRC data present 
If this flag is set four bytes of CRC-32 data is appended to the extended header. The CRC should be 
calculated before unsynchronisation on the data between the extended header and the padding, i.e. the 
frames and only the frames. 


Total frame CRC Soe BGK RE HSK 


3.3. ID3v2 frame overview 


As the tag consists of a tag header and a tag body with one or more frames, all the frames consists of a frame header 
followed by one or more fields containing the actual information. The layout of the frame header: 


Frame ID Sx xx xx xx | (Fol eharackers)) 
Size SHO NOx HG Sox 
Flags Osx Sx 


The frame ID made out of the characters capital A-Z and 0-9. Identifiers beginning with "X", "Y" and "Z" are for 
experimental use and free for everyone to use, without the need to set the experimental bit in the tag header. Have in 
mind that someone else might have used the same identifier as you. All other identifiers are either used or reserved 
for future use. 


The frame ID is followed by a size descriptor, making a total header size of ten bytes in every frame. The size is 
calculated as frame size excluding frame header (frame size - 10). 


In the frame header the size descriptor is followed by two flags bytes. These flags are described in section 3.3.1. 


There is no fixed order of the frames' appearance in the tag, although it is desired that the frames are arranged in 
order of significance concerning the recognition of the file. An example of such order: UFID, TIT2, MCDI, TRCK ... 


A tag must contain at least one frame. A frame must be at least 1 byte big, excluding the header. 


If nothing else is said a string is represented as |SO-8859-1 characters in the range $20 - $FF. Such strings are 
represented as <text string>, or <full text string> if newlines are allowed, in the frame descriptions. All Unicode strings 
use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must begin with the Unicode BOM ($FF FE 
or $FE FF) to identify the byte order. 


All numeric strings and URLs are always encoded as ISO-8859-1. Terminated strings are terminated with $00 if 
encoded with ISO-8859-1 and $00 00 if encoded as unicode. If nothing else is said newline character is forbidden. In 
ISO-8859-1 a new line is represented, when allowed, with $0A only. Frames that allow different types of text encoding 
have a text encoding description byte directly after the frame size. If |SO-8859-1 is used this byte should be $00, if 


Unicode is used it should be $01. Strings dependent on encoding is represented as <text string according to 
encoding>, or <full text string according to encoding> if newlines are allowed. Any empty Unicode strings which are 
NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00). 


The three byte language field is used to describe the language of the frame's content, according to ISO-639-2. 
All URLs may be relative, e.g. "picture.png", "../doc.txt". 


If a frame is longer than it should be, e.g. having more fields than specified in this document, that indicates that 
additions to the frame have been made in a later version of the ID3v2 standard. This is reflected by the revision 
number in the header of the tag. 


—# 3.3.1. Frame header flags 


In the frame header the size descriptor is followed by two flags bytes. All unused flags must be cleared. The first byte 
is for 'status messages' and the second byte is for encoding purposes. If an unknown flag is set in the first byte the 
frame may not be changed without the bit cleared. If an unknown flag is set in the second byte it is likely to not be 
readable. The flags field is defined as follows. 


sabc00000 %13k00000 


a - Tag alter preservation 
This flag tells the software what to do with this frame if it is unknown and the tag is altered in any way. This 
applies to all kinds of alterations, including adding more padding and reordering the frames. 


0 Frame should be preserved. 
ib Frame should be discarded. 


b - File alter preservation 
This flag tells the software what to do with this frame if it is unknown and the file, excluding the tag, is altered. 
This does not apply when the audio is completely replaced with other audio data. 


0 Frame should be preserved. 
il Frame should be discarded. 


c - Read only 
This flag, if set, tells the software that the contents of this frame is intended to be read only. Changing the 
contents might break something, e.g. a signature. If the contents are changed, without knowledge in why the 
frame was flagged read only and without taking the proper means to compensate, e.g. recalculating the 
signature, the bit should be cleared. 


i - Compression 
This flag indicates whether or not the frame is compressed. 


0 Frame is not compressed. 
i! Frame is compressed using [#ZLIB zlib] with 4 bytes for 'decompressed 


size' appended to the frame header. 


j- Encryption 


This flag indicates wether or not the frame is enrypted. If set one byte indicating with which method it was 
encrypted will be appended to the frame header. See section 4.26. for more information about encryption 
method registration. 


0 Frame is not encrypted. 
il Frame is encrypted. 


k - Grouping identity 


This flag indicates whether or not this frame belongs in a group with other frames. If set a group identifier byte 
is added to the frame header. Every frame with the same group identifier belongs to the same group. 


0 Frame does not contain group information 


iL Frame contains group information 


Some flags indicates that the frame header is extended with additional information. This information will be added to 
the frame header in the same order as the flags indicating the additions. |.e. the four bytes of decompressed size will 
precede the encryption method byte. These additions to the frame header, while not included in the frame header 
size but are included in the ‘frame size' field, are not subject to encryption or compression. 


3.4. Default flags 


The default settings for the frames described in this document can be divided into the following classes. The flags 
may be set differently if found more suitable by the software. 


1. Discarded if tag is altered, discarded if file is altered. 


None. 


2. Discarded if tag is altered, preserved if file is altered. 


None. 


3. Preserved if tag is altered, discarded if file is altered. 
AENC, ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ 


4. Preserved if tag is altered, preserved if file is altered. 
The rest of the frames. 


4. Declared ID3v2 frames 


The following frames are declared in this draft. 


4.20 AENC [#sec4.20|Audio encryption] ] 

AN rile, APIC #sec4.15 Attached picture] 

Apeilels COMM #sec4.11 Comments] 

AS) COMR #sec4.25 Commercial frame] 

4.26 ENCR #sec4.26 Encryption method registration] 
4.13 EQUA #sec4.13 Equalization 

4.6 ETCO #sec4.6 Event timing codes] 

4.16 GEOB #sec4.16 General encapsulated object] 
4.27 GRID #sec4.27 Group identification registration] 
4.4 TPLS #sec4.4 Involved people list] 

4.21 LINK #sec4.21 Linked information] 

4.5 MCDI #sec4.5 Music CD identifier] 

4.7 MLLT #sec4.7 MPEG location lookup table] 

4.24 OWNE #sec4.24 Ownership frame 

4.28 PRIV #sec4.28 Private frame 

4.17 PCNT #sec4.17 Play counter] 

4.18 POPM #sec4.18 Popularimeter 

4.22 POSS #sec4.22 Position synchronisation frame] 
4.19 RBUF #sec4.19 Recommended buffer size] 

Areili2 RVAD #sec4.12 Relative volume adjustment] 

Al a RVRB #sec4.14 Reverb] 

4.10 SYLT #sec4.10 Synchronized lyric/text] 

4.8 Sale #sec4.8 Synchronized tempo codes] 
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Original release year] 


File owner/licensee] 
Lead performer(s)/Soloist(s) ] 
Band/orchestra/accompaniment ] 


Conductor/performer refinement] 


Interpreted, remixed, or otherwise modified by] 
Part of a set] 

Publisher] 

Track number/Position in set] 

Recording dates] 

Internet radio station name] 

Internet radio station owner] 

Size] 

ISRC (international standard recording code) ] 


' Software/Hardware and settings used for encoding] 


Year] 
User defined text information frame] 


.1 Unique file identifier] 
.23 Terms of use] 
.9 Unsychronized lyric/text transcription] 


Commercial information] 
Copyright/Legal information] 
Official audio file webpage] 


Official artist/performer webpage] 
Official audio source webpage] 

Official internet radio station homepage] 
Payment 
Publishers official webpage] 
User defined URL link frame] 


4.1. Unique file identifier 


This frame's purpose is to be able to identify the audio file in a database that may contain more information relevant 


to the content. Since standardisation of such a database is beyond this document, all frames begin with a null- 
terminated string with a URL containing an email address, or a link to a location where an email address can be 
found, that belongs to the organisation responsible for this specific database implementation. Questions regarding the 
database should be sent to the indicated email address. The URL should not be used for the actual database queries. 


The string " L? http:/Awww.id3.org/dummy/ufid.html" should be used for tests. Software that isn't told otherwise may 
safely remove such frames. The 'Owner identifier’ must be non-empty (more than just a termination). The 'Owner 
identifier’ is then followed by the actual identifier, which may be up to 64 bytes. There may be more than one "UFID" 
frame in a tag, but only one with the same ‘Owner identifier’. 


<Header for 'Unique file identifier', ID: "UFID"> 
Owner identifier <text string> $00 


Identifier <up to 64 bytes binary data> 


4.2. Text information frames 


The text information frames are the most important frames, containing information like artist, album and more. There 
may only be one text information frame of its kind in an tag. If the textstring is followed by a termination ($00 (00)) all 
the following information should be ignored and not be displayed. All text frame identifiers begin with "T". Only text 
frame identifiers begin with "T", with the exception of the "TXXX" frame. All the text information frames have the 
following format: 


<Header for esc antormablon =rame" 7 1D a OOO = AAA escelieaincg) ix 
described in 4.2.2.> 

Text encoding Grex 

Information <bext String according ro. encoding-= 


8 4.2.1. Text information frames - details 


TALB 
The 'Album/Movie/Show title’ frame is intended for the title of the recording(/source of sound) which the audio 
in the file is taken from. 


TBPM 
The 'BPM' frame contains the number of beats per minute in the mainpart of the audio. The BPM is an integer 
and represented as a numerical string. 


TCOM 
The 'Composer(s)' frame is intended for the name of the composer(s). They are seperated with the "/" 
character. 


TCON 


The 'Content type’, which previously was stored as a one byte numeric value only, is now a numeric string. 
You may use one or several of the types as ID3v1.1 did or, since the category list would be impossible to 
maintain with accurate and up to date categories, define your own. 


References to the ID3v1 genres can be made by, as first byte, enter "(" followed by a number from the genres 
list (appendix A) and ended with a")" character. This is optionally followed by a refinement, e.g. "(21)" or" 
(4)Eurodisco". Several references can be made in the same frame, e.g. "(51)(39)". If the refinement should 
begin with a "(" character it should be replaced with "((", e.g. "((I can figure out any genre)" or "(55)((I think...)". 
The following new content types is defined in ID3v2 and is implemented in the same way as the numerig 
content types, e.g. "(RX)". 


RX Remix 


CR Cover 


TCOP 
The 'Copyright message’ frame, which must begin with a year and a space character (making five characters), 
is intended for the copyright holder of the original sound, not the audio file itself. The absence of this frame 
means only that the copyright information is unavailable or has been removed, and must not be interpreted to 
mean that the sound is public domain. Every time this field is displayed the field must be preceded with 
"Copyright © ". 


TDAT 


The 'Date' frame is a numeric string in the DDMM format containing the date for the recording. This field is 
always four characters long. 


TDLY 
The 'Playlist delay' defines the numbers of milliseconds of silence between every song in a playlist. The player 
should use the "ETC" frame, if present, to skip initial silence and silence at the end of the audio to match the 
‘Playlist delay’ time. The time is represented as a numeric string. 


TENC 


The 'Encoded by' frame contains the name of the person or organisation that encoded the audio file. This field 
may contain a copyright message, if the audio file also is copyrighted by the encoder. 


TEXT 


The 'Lyricist(s)/Text writer(s)' frame is intended for the writer(s) of the text or lyrics in the recording. They are 
seperated with the "/" character. 


TFLT 


The 'File type' frame indicates which type of audio this tag defines. The following type and refinements are 
defined: 


MPG MPEG Audio 
fst MPEG 1/2 layer I 
Ve MPEG 1/2 layer II 
/3 MPEG 1/2 layer III 
Pies MPEG 2.5 
/BAC Advanced audio compression 
VOF Transform-domain Weighted Interleave Vector Quantization 
PCM Pulse Code Modulated audio 


but other types may be used, not for these types though. This is used in a similar way to the predefined types in the 
"TMED" frame, but without parentheses. If this frame is not present audio type is assumed to be "MPG". 


TIME 


The 'Time' frame is a numeric string in the HHMM format containing the time for the recording. This field is 
always four characters long. 


TIT1 


The 'Content group description’ frame is used if the sound belongs to a larger category of sounds/music. For 
example, classical music is often sorted in different musical sections (e.g. "Piano Concerto", "Weather - 
Hurricane"). 


TIT2 


The 'Title/Songname/Content description’ frame is the actual name of the piece (e.g. "Adagio", "Hurricane 
Donna"). 


TIT3 
The 'Subtitle/Description refinement’ frame is used for information directly related to the contents title (e.g. "Op. 


16" or "Performed live at Wembley"). 


TKEY 


The ‘Initial key’ frame contains the musical key in which the sound starts. It is represented as a string with a 
maximum length of three characters. The ground keys are represented with "A","B","C","D","E", "F" and "G" 
and halfkeys represented with "b" and "#". Minor is represented as "m". Example "Cbm". Off key is 


represented with an "o" only. 


TLAN 


The 'Language(s)' frame should contain the languages of the text or lyrics spoken or sung in the audio. The 
language is represented with three characters according to ISO-639-2. If more than one language is used in 


the text their language codes should follow according to their usage. 


TLEN 


The 'Length' frame contains the length of the audiofile in milliseconds, represented as a numeric string. 


TMED 


The 'Media type' frame describes from which media the sound originated. This may be a text string or a 
reference to the predefined media types found in the list below. References are made within "(" and ")" and are 
optionally followed by a text refinement, e.g. "(MC) with four channels". If a text refinement should begin with a 
"(" character it should be replaced with "((" in the same way as in the "TCO" frame. Predefined refinements is 


appended after the media type, e.g. "(CD/A)" or "(VID/PAL/VHS)". 


DIG 
/A 


ANA 
/WAC 
/8CA 


cD 
/A 
/DD 
/AD 
/BA 


LD 
/A 


ww 
{33 
/45 
aes 
/76 
aS 
/80 


MD 
/A 


DAT 
/A 
Pil 
Ve 
f3 
/4 
LS 


Other digital media 


Analog transfer from media 


Other analog media 


Wax 
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rack tape cassette 


Analog transfer from media 


DDD 
ADD 
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Las 


erdisc 
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4, 32 kHz/12 bits, 4 channels 
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linear 


low speed 


/6 


DCC 
/A 


DVD 
/A 


mmorele: 1G, GC aL Ikisika/ IL lenlies 


HEE 


Analog transfer from media 


DVD 
Ana 


log transfer from media 


Television 
PAL 
INIESC 


SECAM 


Video 
PAL 
NTSC 


SECAM 


VHS 
S-VHS 
B 


FE TAMAX 


MC 


TOAL 


Telephone 
ISDN 


MC (normal cassette) 
AWS ems 
9.5 cm/s 


™ 


I Cesseicce 


™ 


II cassette (chrome) 
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LiL GAagsSseiece 
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IV cassette (metal) 


Reel 

1.5 ens 
19 cm/s 
simem/s 
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i Gasseince 
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II cassette (chrome) 


™ 


LLL Caseeicce 


™ 


IV cassette (metal) 


"wide track' 


(normal speed for a two sided cassette) 


(ferric/normal) 


(ferric chrome) 


(ferric/normal) 


(ferric chrome) 


The ‘Original album/movie/show title’ frame is intended for the title of the original recording (or source of 
sound), if for example the music in the file should be a cover of a previously released song. 


TOFN 
The ‘Original filename’ frame contains the preferred filename for the file, since some media doesn't allow the 
desired length of the filename. The filename is case sensitive and includes its suffix. 


TOLY 


The ‘Original lyricist(s)/text writer(s)' frame is intended for the text writer(s) of the original recording, if for 
example the music in the file should be a cover of a previously released song. The text writers are seperated 
with the "/" character. 


TOPE 
The ‘Original artist(s)/performer(s)' frame is intended for the performer(s) of the original recording, if for 
example the music in the file should be a cover of a previously released song. The performers are seperated 
with the "/" character. 


TORY 
The ‘Original release year' frame is intended for the year when the original recording, if for example the music 
in the file should be a cover of a previously released song, was released. The field is formatted as in the 
"TYER" frame. 


TOWN 
The 'File owner/licensee' frame contains the name of the owner or licensee of the file and it's contents. 


TPE1 
The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is used for the main artist(s). They are 
seperated with the "/" character. 


TPE2 
The 'Band/Orchestra/Accompaniment' frame is used for additional information about the performers in the 
recording. 


TPE3 
The 'Conductor' frame is used for the name of the conductor. 


TPE4 
The 'Interpreted, remixed, or otherwise modified by' frame contains more information about the people behind 
a remix and similar interpretations of another existing piece. 


TPOS 
The 'Part of a set' frame is a numeric string that describes which part of a set the audio came from. This frame 
is used if the source described in the "TALB" frame is divided into several mediums, e.g. a double CD. The 
value may be extended with a "/" character and a numeric string containing the total number of parts in the set. 
E.g. "1/2". 


TPUB 
The 'Publisher' frame simply contains the name of the label or publisher. 


TRCK 
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its 
original recording. This may be extended with a "/" character and a numeric string containing the total numer of 
tracks/elements on the original recording. E.g. "4/9". 


TRDA 
The 'Recording dates' frame is a intended to be used as complement to the "TYER", "TDAT" and "TIME" 
frames. E.g. "4th-7th June, 12th June” in combination with the "TYER" frame. 


TRSN 
The ‘Internet radio station name' frame contains the name of the internet radio station from which the audio is 
streamed. 


TRSO 
The 'Internet radio station owner’ frame contains the name of the owner of the internet radio station from which 
the audio is streamed. 


TSIZ 


The 'Size' frame contains the size of the audiofile in bytes, excluding the ID3v2 tag, represented as a numeric 
string. 


TSRC 
The 'ISRC' frame should contain the International Standard Recording Code (ISRC) (12 characters). 


TSSE 
The 'Software/Hardware and settings used for encoding’ frame includes the used audio encoder and its 
settings when the file was encoded. Hardware refers to hardware encoders, not the computer on which a 
program was run. 


TYER 
The 'Year' frame is a numeric string with a year of the recording. This frames is always four characters long 
(until the year 10000). 


—§ 4.2.2. User defined text information frame 


This frame is intended for one-string text information concerning the audiofile in a similar way to the other "T"-frames. 
The frame body consists of a description of the string, represented as a terminated string, followed by the actual 
string. There may be more than one "TXXxX" frame in each tag, but only one with the same description. 


<Header for 'User defined text information frame', ID: "TXXX"> 


Text encoding Sxx 
Description <text string according to encoding> $00 (00) 
Value <text string according to encoding> 


4.3. URL link frames 


With these frames dynamic data such as webpages with touring information, price information or plain ordinary news 
can be added to the tag. There may only be one URL link frame of its kind in an tag, except when stated otherwise in 
the frame description. If the textstring is followed by a termination ($00 (00)) all the following information should be 
ignored and not be displayed. All URL link frame identifiers begins with "W". Only URL link frame identifiers begins 
with "W". All URL link frames have the following format: 


<Header for 'URL link frame', ID: "WOOO" - "WZZZ", excluding "WXXX" described in 
AS 2 
URL <text string> 


8 4.3.1. URL link frames - details 


WCOM 
The 'Commercial information’ frame is a URL pointing at a webpage with information such as where the album 
can be bought. There may be more than one "WCOM" frame in a tag, but not with the same content. 


WCOP 
The 'Copyright/Legal information’ frame is a URL pointing at a webpage where the terms of use and ownership 
of the file is described. 


WOAF 
The ‘Official audio file webpage’ frame is a URL pointing at a file specific webpage. 


WOAR 
The ‘Official artist/performer webpage’ frame is a URL pointing at the artists official webpage. There may be 
more than one "WOAR" frame in a tag if the audio contains more than one performer, but not with the same 


content. 


WOAS 
The ‘Official audio source webpage’ frame is a URL pointing at the official webpage for the source of the audio 
file, e.g. a movie. 


WORS 
The ‘Official internet radio station homepage’ contains a URL pointing at the homepage of the internet radio 
station. 


WPAY 
The 'Payment' frame is a URL pointing at a webpage that will handle the process of paying for this file. 


WPUB 
The 'Publishers official webpage' frame is a URL pointing at the official wepage for the publisher. 


8 4.3.2. User defined URL link frame 


This frame is intended for URL links concerning the audiofile in a similar way to the other "W"-frames. The frame body 
consists of a description of the string, represented as a terminated string, followed by the actual URL. The URL is 
always encoded with ISO-8859-1. There may be more than one "WXXxX" frame in each tag, but only one with the 
same description. 


<Header for 'User defined URL link frame', ID: "WXXX"> 


Text encoding BECK 
Description <text string according to encoding> $00 (00) 
URL <text string> 


4.4. Involved people list 


Since there might be a lot of people contributing to an audio file in various ways, such as musicians and technicians, 
the 'Text information frames' are often insufficient to list everyone involved in a project. The ‘Involved people list' is a 
frame containing the names of those involved, and how they were involved. The body simply contains a terminated 
string with the involvement directly followed by a terminated string with the involvee followed by a new involvement 
and so on. There may only be one "IPLS" frame in each tag. 


<Header for ‘Involved people list', ID: "IPLS"> 
Text encoding Oeex 
People list strings <text strings according to encoding> 


4.5. Music CD identifier 


This frame is intended for music that comes from a CD, so that the CD can be identified in databases such as the 
CDDB. The frame consists of a binary dump of the Table Of Contents, TOC, from the CD, which is a header of 4 
bytes and then 8 bytes/track on the CD plus 8 bytes for the ‘lead out' making a maximum of 804 bytes. The offset to 
the beginning of every track on the CD should be described with a four bytes absolute CD-frame address per track, 
and not with absolute time. This frame requires a present and valid "TRCK" frame, even if the CD's only got one 
track. There may only be one "MCDI" frame in each tag. 


Header sho Musnic Cli neem erste rele lec liane 
CD MOC doliimaicy claica> 


4.6. Event timing codes 


This frame allows synchronisation with key events in a song or sound. The header is: 


<Header for ‘Event timing codes', ID: "ETCO"> 
Time stamp format SO 


Where time stamp format is: 


$01 Absolute time, 32 bit sized, using MPEG frames as unit 
$02 Absolute time, 32 bit sized, using milliseconds as unit 


Abolute time means that every stamp contains the time from the beginning of the file. 


Followed by a list of key events in the following format: 


Type of event Sixx 


Time stamp Sree (OS ana) 


The 'Time stamp' is set to zero if directly at the beginning of the sound or after the previous event. All events should 
be sorted in chronological order. The type of event is as follows: 


$00 padding (has no meaning) 
SOL end of initial silence 
SO2 IMEIeS) Bicester 

S03 mainpart start 

S04 QUO Sicsucce 

$05 outro end 

$06 verse start 

S017 refrain start 

$08 interlude start 

$09 theme start 

SOA WEWELANCILOI BIEeNeE 

SOB key change 

SOC time change 

SOD momentary unwanted noise (Snap, Crackle & Pop) 
SOE sustained noise 

SOF sustained noise end 

$10 intro end 

Sil i mainpart end 

Sil 2 verse end 

Sis refrain end 

Sule theme end 

S15-SDF reserved for future use 
SEO-SEF not predefined sync 0-F 


SFO-SFC reserved for future use 


SED audio end (start of silence) 
SFE audio file ends 
SEF one more byte of events follows (all the following bytes with the value SFF 


have the same function) 


Terminating the start events such as "intro start" is not required. The 'Not predefined sync's ($E0-EF) are for user 
events. You might want to synchronise your music to something, like setting of an explosion on-stage, turning on your 
screensaver etc. 


There may only be one "ETCO" frame in each tag. 


4.7. MPEG location lookup table 


To increase performance and accuracy of jumps within a MPEG audio file, frames with timecodes in different 
locations in the file might be useful. The ID3v2 frame includes references that the software can use to calculate 
positions in the file. After the frame header is a descriptor of how much the ‘frame counter’ should increase for every 
reference. If this value is two then the first reference points out the second frame, the 2nd reference the 4th frame, 
the 3rd reference the 6th frame etc. In a similar way the 'bytes between reference’ and 'milliseconds between 
reference’ points out bytes and milliseconds respectively. 


Each reference consists of two parts; a certain number of bits, as defined in 'bits for bytes deviation’, that describes 
the difference between what is said in 'bytes between reference’ and the reality and a certain number of bits, as 
defined in 'bits for milliseconds deviation’, that describes the difference between what is said in ‘milliseconds between 
reference’ and the reality. The number of bits in every reference, i.e. 'bits for bytes deviation'+'bits for milliseconds 
deviation’, must be a multiple of four. There may only be one "MLLT" frame in each tag. 


<Header for "Location lookup table', ID: "MLLT"> 


MPEG frames between referenc SNe SOx 
Bytes between referenc Sask BOK eK 
Milliseconds between referenc Sie SOK BOK 
Bits for bytes deviation SxxX 

Bits for milliseconds dev. Sox 


Then for every reference the following data is included; 


Deviation in bytes Le Oe ae 
Deviation in milliseconds %xxx.... 


4.8. Synchronised tempo codes 


For a more accurate description of the tempo of a musical piece this frame might be used. After the header follows 
one byte describing which time stamp format should be used. Then follows one or more tempo codes. Each tempo 
code consists of one tempo part and one time part. The tempo is in BPM described with one or two bytes. If the first 
byte has the value $FF, one more byte follows, which is added to the first giving a range from 2 - 510 BPM, since $00 
and $01 is reserved. $00 is used to describe a beat-free time period, which is not the same as a music-free time 
period. $01 is used to indicate one single beat-stroke followed by a beat-free period. 


The tempo descriptor is followed by a time stamp. Every time the tempo in the music changes, a tempo descriptor 
may indicate this for the player. All tempo descriptors should be sorted in chronological order. The first beat-stroke in 
a time-period is at the same time as the beat description occurs. There may only be one "SYTC" frame in each tag. 


<Header for ‘'Synchronised tempo codes', ID: "SYTC"> 
Time stamp format Sy 


Tempo data <binary data> 


Where time stamp format is: 


$01 Absolute time, 32 bit sized, using MPEG frames as unit 
$02 Absolute time, 32 bit sized, using milliseconds as unit 


Abolute time means that every stamp contains the time from the beginning of the file. 


4.9. Unsychronised lyrics/text transcription 


This frame contains the lyrics of the song or a text transcription of other vocal activities. The head includes an 
encoding descriptor and a content descriptor. The body consists of the actual text. The 'Content descriptor’ is a 
terminated string. If no descriptor is entered, 'Content descriptor’ is $00 (00) only. Newline characters are allowed in 
the text. There may be more than one 'Unsynchronised lyrics/text transcription’ frame in each tag, but only one with 
the same language and content descriptor. 


<Header for 'Unsynchronised lyrics/text transcription’, ID: "“USLT"> 


Text encoding SXxX 

Language ExSK EOL LOX 

Content descriptor <text string according to encoding> $00 (00) 
Lyrics/text <full text string according to encoding> 


4.10. Synchronised lyrics/text 


This is another way of incorporating the words, said or sung lyrics, in the audio file as text, this time, however, in sync 
with the audio. It might also be used to describing events e.g. occurring on a stage or on the screen in sync with the 
audio. The header includes a content descriptor, represented with as terminated textstring. If no descriptor is entered, 
‘Content descriptor’ is $00 (00) only. 


—Headere fom suSvnchtonisedalyictes /tesca, Lbs Svan ll 


Text encoding SxSx 
Language Grok BOK BOK 
Time stamp format Gro 
Content type Sxx 


Content descriptor <text string according to encoding> $00 (00) 


Encoding: 

$00 ITSO-8859-1 character set is used => $00 is sync identifier. 
S(O il Unicode character set is used => $00 00 is sync identifier. 
Content type: 

$00 is other 

S01 1s Iyer 

$02 ESM CScieme Etaoin S © leo itedkoimn 

S03 is movement/part name (e.g. "Adagio") 

S04 is events (e.g. "Don Quijot nters the stage") 

S105) Ls Clrorcl (Sse, Visio i wisi) 

$06 iS iEveslwAlel// Yiereys) ibys)! alioit@iaqmelte Loin 


Time stamp format is: 


$01 Absolute time, 32 bit sized, using MPEG frames as unit 


$02 Absolute time, 32 bit sized, using milliseconds as unit 


Abolute time means that every stamp contains the time from the beginning of the file. 


The text that follows the frame header differs from that of the unsynchronised lyrics/text transcription in one major 
way. Each syllable (or whatever size of text is considered to be convenient by the encoder) is a null terminated string 
followed by a time stamp denoting where in the sound file it belongs. Each sync thus has the following structure: 


Terminated text to be synced (typically a syllable) 
Syne identifier (terminator to above string) $00 (00) 
Time stamp Ssex (S62 goa) 


The ‘time stamp' is set to zero or the whole sync is omitted if located directly at the beginning of the sound. All time 
stamps should be sorted in chronological order. The sync can be considered as a validator of the subsequent string. 


Newline ($0A) characters are allowed in all "SYLT" frames and should be used after every entry (name, event etc.) in 
a frame with the content type $03 - $04. 


A few considerations regarding whitespace characters: Whitespace separating words should mark the beginning of a 
new word, thus occurring in front of the first syllable of a new word. This is also valid for new line characters. A 
syllable followed by a comma should not be broken apart with a sync (both the syllable and the comma should be 
before the sync). 


An example: The "USLT" passage 


"Strangers in the night" SOA "Exchanging glances" 


would be "SYLT" encoded as: 


WSicicemce SOO sox sox Vers! SOO sex sox VY aia” SOO sex sox Y tele” SOO 
xox sox imagine” SOO soe sox OA Wax” SOO xox sox Yelaaine” SOO sex xox 


WalinteiY (S00) sox sex “olla” SOO) sex soe Vees SOW) sex xox 


There may be more than one "SYLT" frame in each tag, but only one with the same language and content descriptor. 


4.11. Comments 


This frame is indended for any kind of full text information that does not fit in any other frame. It consists of a frame 
header followed by encoding, language and content descriptors and is ended with the actual comment as a text 
string. Newline characters are allowed in the comment text string. There may be more than one comment frame in 
each tag, but only one with the same language and content descriptor. 


<Header for 'Comment', ID: "COMM"> 

Text encoding oxox 

Language SEGe Lox BOK 

Short content descrip. <text string according to encoding> $00 (00) 


The actual text <ul abe xrms FEinGmace ore inigmcomeoncod lung 


4.12. Relative volume adjustment 


This is a more subjective function than the previous ones. It allows the user to say how much he wants to 
increase/decrease the volume on each channel while the file is played. The purpose is to be able to align all files to a 
reference volume, so that you don't have to change the volume constantly. This frame may also be used to balance 
adjust the audio. If the volume peak levels are known then this could be described with the 'Peak volume right’ and 
‘Peak volume left' field. If Peakvolume is not known these fields could be left zeroed or, if no other data follows, be 
completely omitted. There may only be one "RVAD" frame in each tag. 


<Header for ‘Relative volume adjustment', ID: "RVAD"> 


Increment/decrement SOOxXXXXXX 
Bits used for volume descr. Sxx 


Relative volume change, right Seok ROL (KEK oc) 


Relative volume change, left Byex BOX (GOK ca) 
Peak volume right SxSK Roe (KEK coc) 


Peak volume left Sox SOK (REE oon) 


In the increment/decrement field bit 0 is used to indicate the right channel and bit 1 is used to indicate the left 
channel. 1 is increment and 0 is decrement. 


The 'bits used for volume description’ field is normally $10 (16 bits) for MPEG 2 layer I, Il and Ill and MPEG 2.5. This 
value may not be $00. The volume is always represented with whole bytes, padded in the beginning (highest bits) 
when 'bits used for volume description’ is not a multiple of eight. 


This datablock is then optionally followed by a volume definition for the left and right back channels. If this information 
is appended to the frame the first two channels will be treated as front channels. In the increment/decrement field bit 
2 is used to indicate the right back channel and bit 3 for the left back channel. 


Relative volume change, right back SHOR ES (2 ooo) 
Relative volume change, left back BRGk Sox (662 4.54), 
Peak volume right back SEOK BOK (ROR oc) 
Peak volume left back SRGx ROK (sex =) 


If the center channel adjustment is present the following is appended to the existing frame, after the left and right 
back channels. The center channel is represented by bit 4 in the increase/decrease field. 


Relative volume change, center S$xx xx (xx ...) 
Peak volume center SOS BES ROS Gates) 


If the bass channel adjustment is present the following is appended to the existing frame, after the center channel. 
The bass channel is represented by bit 5 in the increase/decrease field. 


Relative volume change, bass Se ao (ee) 
Peak volume bass Sox BOX (FOX 56a) 


4.13. Equalisation 


This is another subjective, alignment frame. It allows the user to predefine an equalisation curve within the audio file. 
There may only be one "EQUA" frame in each tag. 


<Header of 'Equalisation', ID: "EQUA"> 
Adjustment bits Sxx 


The ‘adjustment bits' field defines the number of bits used for representation of the adjustment. This is normally $10 
(16 bits) for MPEG 2 layer |, Il and IIl and MPEG 2.5. This value may not be $00. 


This is followed by 2 bytes + (‘adjustment bits' rounded up to the nearest byte) for every equalisation band in the 
following format, giving a frequency range of 0 - 32767Hz: 


Increment/decrement Sx (MSB of the Frequency) 
Frequency (lower 15 bits) 
Adjustment SESK (S254) 


The increment/decrement bit is 1 for increment and 0 for decrement. The equalisation bands should be ordered 
increasingly with reference to frequency. All frequencies don't have to be declared. The equalisation curve in the 
reading software should be interpolated between the values in this frame. Three equal adjustments for three 
subsequent frequencies. A frequency should only be described once in the frame. 


4.14. Reverb 


Yet another subjective one. You may here adjust echoes of different kinds. Reverb left/right is the delay between 
every bounce in ms. Reverb bounces left/right is the number of bounces that should be made. $FF equals an infinite 
number of bounces. Feedback is the amount of volume that should be returned to the next echo bounce. $00 is 0%, 
$FF is 100%. If this value were $7F, there would be 50% volume reduction on the first bounce, 50% of that on the 
second and so on. Left to left means the sound from the left bounce to be played in the left speaker, while left to right 
means sound from the left bounce to be played in the right speaker. 


'Premix left to right’ is the amount of left sound to be mixed in the right before any reverb is applied, where $00 id 0% 
and $FF is 100%. 'Premix right to left' does the same thing, but right to left. Setting both premix to $FF would result in 
a mono output (if the reverb is applied symmetric). There may only be one "RVRB" frame in each tag. 


<Header for 'Reverb', ID: "RVRB"> 


Reverb left (ms) Sue Hox 
Reverb right (ms) Ssox Sox 
Reverb bounces, left SROX 
Reverb bounces, right Sex 


Reverb feedback, left to left Sox 
Reverb feedback, left to right $xx 
Reverb feedback, right to right $xx 
Reverb feedback, right to left $xx 
Premix left to right SXx 


Premix right to left SyOx 


4.15. Attached picture 


This frame contains a picture directly related to the audio file. Image format is the MIME type and subtype for the 
image. In the event that the MIME media type name is omitted, "image/" will be implied. The "image/png" or 
"image/jpeg" picture format should be used when interoperability is wanted. Description is a short description of the 
picture, represented as a terminated textstring. The description has a maximum length of 64 characters, but may be 
empty. There may be several pictures attached to one file, each in their individual "APIC" frame, but only one with the 
same content descriptor. There may only be one picture with the picture type declared as picture type $01 and $02 
respectively. There is the possibility to put only a link to the image file by using the 'MIME type’ "-->" and having a 
complete URL instead of picture data. The use of linked files should however be used sparingly since there is the risk 
of separation of files. 


<Header for ‘Attached picture', ID: "APIC"> 


Text encoding Spex 

MIME type <text string> $00 

Picture type SxxX 

Description <text string according to encoding> $00 (00) 
Picture data <binary data> 


Picture type: 


$00 Other 

SO 32x32 pixels 'file icon' (PNG only) 
S10 Other file icon 

$03 Cover (front) 

S04 Cover (back) 

$05 Leaflet page 

$06 Media (e.g. lable side of CD) 


S07 Lead artist/lead performer/soloist 


$08 Artist/performer 


$09 Conductor 

SOA Band/Orchestra 

SOB Composer 

SIOG Lyricist/text writer 

SOD Recording Location 

SOE During recording 

SOF During performance 

$10 Movie/video screen capture 
SIL i A bright coloured fish 
S12 IPL UIE eNe LOM 

Sls} Band/artist logotype 

$14 Publisher/Studio logotype 


4.16. General encapsulated object 


In this frame any type of file can be encapsulated. After the header, 'Frame size’ and 'Encoding' follows 'MIME type' 
represented as as a terminated string encoded with ISO-8859-1. The filename is case sensitive and is encoded as 
‘Encoding’. Then follows a content description as terminated string, encoded as ‘Encoding’. The last thing in the frame 
is the actual object. The first two strings may be omitted, leaving only their terminations. There may be more than one 
"GEOB" frame in each tag, but only one with the same content descriptor. 


<Header for ‘General encapsulated object', ID: "GEOB"> 


Text encoding SxXxX 

MIME type <text string> $00 

Filename <text string according to encoding> $00 (00) 
Content description $00 (00) 

Encapsulated object <binary data> 


4.17. Play counter 


This is simply a counter of the number of times a file has been played. The value is increased by one every time the 
file begins to play. There may only be one "PCNT" frame in each tag. When the counter reaches all one's, one byte is 
inserted in front of the counter thus making the counter eight bits bigger. The counter must be at least 32-bits long to 
begin with. 


<Header for 'Play counter', ID: "PCNT"> 
Counter Sire BEC BOG BO (RSE goa) 


4.18. Popularimeter 


The purpose of this frame is to specify how good an audio file is. Many interesting applications could be found to this 
frame such as a playlist that features better audiofiles more often than others or it could be used to profile a person's 
taste and find other 'good' files by comparing people's profiles. The frame is very simple. It contains the email address 
to the user, one rating byte and a four byte play counter, intended to be increased with one for every time the file is 
played. The email is a terminated string. The rating is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no 
personal counter is wanted it may be omitted. When the counter reaches all one's, one byte is inserted in front of the 
counter thus making the counter eight bits bigger in the same away as the play counter ("PCNT"). There may be more 
than one "POPM'" frame in each tag, but only one with the same email address. 


<Header for 'Popularimeter', ID: "POPM"> 
Email to user <text string> $00 


Rating Syn 


Counter Sox SEK SS BSR (ROK Go) 


4.19. Recommended buffer size 


Sometimes the server from which a audio file is streamed is aware of transmission or coding problems resulting in 
interruptions in the audio stream. In these cases, the size of the buffer can be recommended by the server using this 
frame. If the 'embedded info flag' is true (1) then this indicates that an ID3 tag with the maximum size described in 
‘Buffer size’ may occur in the audiostream. In such case the tag should reside between two MPEG frames, if the 
audio is MPEG encoded. If the position of the next tag is known, ‘offset to next tag' may be used. The offset is 
calculated from the end of tag in which this frame resides to the first byte of the header in the next. This field may be 
omitted. Embedded tags are generally not recommended since this could render unpredictable behaviour from 
present software/hardware. 


For applications like streaming audio it might be an idea to embed tags into the audio stream though. If the clients 
connects to individual connections like HTTP and there is a possibility to begin every transmission with a tag, then 
this tag should include a 'recommended buffer size' frame. If the client is connected to a arbitrary point in the stream, 
such as radio or multicast, then the 'recommended buffer size' frame should be included in every tag. Every tag that is 
picked up after the initial/first tag is to be considered as an update of the previous one. E.g. if there is a "TIT2" frame 
in the first received tag and one in the second tag, then the first should be ‘replaced’ with the second. 


The ‘Buffer size’ should be kept to a minimum. There may only be one "RBUF" frame in each tag. 


<Header for 'Recommended buffer size', ID: "RBUF"> 


Buffer size SeOR BEX Bok 
Embedded info flag S0000000x 
Offset to next tag Sx BGK SSS BOK 


4.20. Audio encryption 


This frame indicates if the actual audio stream is encrypted, and by whom. Since standardization of such encryption 
scheme is beyond this document, all "AENC" frames begin with a terminated string with a URL containing an email 
address, or a link to a location where an email address can be found, that belongs to the organisation responsible for 
this specific encrypted audio file. Questions regarding the encrypted audio should be sent to the email address 
specified. If a $00 is found directly after the 'Frame size’ and the audiofile indeed is encrypted, the whole file may be 
considered useless. 


After the 'Owner identifier’, a pointer to an unencrypted part of the audio can be specified. The 'Preview start’ and 
‘Preview length' is described in frames. If no part is unencrypted, these fields should be left zeroed. After the 'preview 
length’ field follows optionally a datablock required for decryption of the audio. There may be more than one "AENC" 
frames in a tag, but only one with the same ‘Owner identifier’. 


<Header for ‘Audio encryption', ID: "AENC"> 


Owner identifier <text string> $00 
Preview start Sx ROK 

Preview length Seok Box 

Encryption info <binary data> 


4.21. Linked information 


To keep space waste as low as possible this frame may be used to link information from another ID3v2 tag that might 
reside in another audio file or alone in a binary file. It is recommended that this method is only used when the files are 
stored on a CD-ROM or other circumstances when the risk of file seperation is low. The frame contains a frame 


identifier, which is the frame that should be linked into this tag, a URL field, where a reference to the file where the 
frame is given, and additional ID data, if needed. Data should be retrieved from the first tag found in the file to which 
this link points. There may be more than one "LINK" frame in a tag, but only one with the same contents. A linked 
frame is to be considered as part of the tag and has the same restrictions as if it was a physical part of the tag (i.e. 
only one "RVRB" frame allowed, whether it's linked or not). 


<Header for 'Linked information', ID: "LINK"> 
Frame identifier SASk BOK KOK 

URL <text string> Soo 

ID and additional data <text string(s)> 


Frames that may be linked and need no additional data are "IPLS", "MCID", "ETCO", "MLLT", "SYTC", "RVAD", 
"EQUA", "RVRB", "RBUF", the text information frames and the URL link frames. 


The "TXXxX", "APIC", "GEOB" and "AENC" frames may be linked with the content descriptor as additional ID data. 


The "COMM", "SYLT" and "USLT" frames may be linked with three bytes of language descriptor directly followed by a 
content descriptor as additional ID data. 


4.22. Position synchronisation frame 


This frame delivers information to the listener of how far into the audio stream he picked up; in effect, it states the 
time offset of the first frame in the stream. The frame layout is: 


Kiger! st@ie VPS Gyielcomiseiciema!’, Wg WSS" > 
Time stamp format SHOR 


Position Sear (Sh Sa) 


Where time stamp format is: 


$01 Absolute time, 32 bit sized, using MPEG frames as unit 


$02 Absolute time, 32 bit sized, using milliseconds as unit 


and position is where in the audio the listener starts to receive, i.e. the beginning of the next frame. If this frame is 
used in the beginning of a file the value is always 0. There may only be one "POSS" frame in each tag. 


4.23. Terms of use frame 


This frame contains a brief description of the terms of use and ownership of the file. More detailed information 
concerning the legal terms might be available through the "WWCOP" frame. Newlines are allowed in the text. There 
may only be one "USER" frame in a tag. 


<Header for 'Terms of use frame', ID: "USER"> 
Text encoding SXxX 
Language Seok BOX Sex 


The actual text <text string according to encoding> 


4.24. Ownership frame 


The ownership frame might be used as a reminder of a made transaction or, if signed, as proof. Note that the "USER" 
and "TOWN" frames are good to use in conjunction with this one. The frame begins, after the frame ID, size and 
encoding fields, with a 'price payed' field. The first three characters of this field contains the currency used for the 


transaction, encoded according to ISO-4217 alphabetic currency code. Concatenated to this is the actual price payed, 


as a numerical string using "." as the decimal separator. Next is an 8 character date string (YY YYMMDD) followed by 
a string with the name of the seller as the last field in the frame. There may only be one "OWNE" frame in a tag. 


<Header for ‘Ownership frame’, ID: "OWNE"> 
Text encoding Ssex 


Price payed <text string> $00 
Date of purch. <text string> 
Seller <text string according to encoding> 


4.25. Commercial frame 


This frame enables several competing offers in the same tag by bundling all needed information. That makes this 
frame rather complex but it's an easier solution than if one tries to achieve the same result with several frames. The 
frame begins, after the frame ID, size and encoding fields, with a price string field. A price is constructed by one three 
character currency code, encoded according to ISO-4217 alphabetic currency code, followed by a numerical value 
where "." is used as decimal seperator. In the price string several prices may be concatenated, seperated by a "/" 
character, but there may only be one currency of each type. 


The price string is followed by an 8 character date string in the format YYYYMMDD, describing for how long the price 
is valid. After that is a contact URL, with which the user can contact the seller, followed by a one byte 'received as' 
field. It describes how the audio is delivered when bought according to the following list: 


$00 Other 

Soil Standard CD album with other songs 

$02 Compressed audio on CD 

$03 File over the Internet 

$04 Stream over the Internet 

$05 As note sheets 

$06 As note sheets in a book with other sheets 
S0)7/ Music on other media 

$08 Non-musical merchandise 


Next follows a terminated string with the name of the seller followed by a terminated string with a short description of 
the product. The last thing is the ability to include a company logotype. The first of them is the 'Picture MIME type' 
field containing information about which picture format is used. In the event that the MIME media type name is 
omitted, "image/" will be implied. Currently only "image/png" and "image/jpeg" are allowed. This format string is 
followed by the binary picture data. This two last fields may be omitted if no picture is to attach. 


<Header for 'Commercial frame', ID: "COMR"> 


Text encoding SxXX 

NEIL) SETTLING) <text string> $00 

Wallate) juiaest JL. <text string> 

Contact URL <text string> $00 

Received as Spor 

Name of seller <text string according to encoding> $00 (00) 
Description <text string according to encoding> $00 (00) 
Picture MIME type <string> $00 

Seller logo <binary data> 


4.26. Encryption method registration 


To identify with which method a frame has been encrypted the encryption method must be registered in the tag with 


this frame. The 'Owner identifier’ is a null-terminated string with a URL containing an email address, or a link toa 
location where an email address can be found, that belongs to the organisation responsible for this specific 
encryption method. Questions regarding the encryption method should be sent to the indicated email address. The 
‘Method symbol’ contains a value that is associated with this method throughout the whole tag. Values below $80 are 
reserved. The 'Method symbol’ may optionally be followed by encryption specific data. There may be several "ENCR" 
frames in a tag but only one containing the same symbol and only one containing the same owner identifier. The 
method must be used somewhere in the tag. See section 3.3.1, flag j for more information. 


<Header for ‘Encryption method registration', ID: "ENCR"> 
Owner identifier <Eext String> Sido 

Method symbol Sex 

Encryption data <binary data> 


4.27. Group identification registration 


This frame enables grouping of otherwise unrelated frames. This can be used when some frames are to be signed. 
To identify which frames belongs to a set of frames a group identifier must be registered in the tag with this frame. 
The ‘Owner identifier’ is a null-terminated string with a URL containing an email address, or a link to a location where 
an email address can be found, that belongs to the organisation responsible for this grouping. Questions regarding 
the grouping should be sent to the indicated email address. The 'Group symbol’ contains a value that associates the 
frame with this group throughout the whole tag. Values below $80 are reserved. The 'Group symbol’ may optionally 
be followed by some group specific data, e.g. a digital signature. There may be several "GRID" frames in a tag but 
only one containing the same symbol and only one containing the same owner identifier. The group symbol must be 
used somewhere in the tag. See section 3.3.1, flag j for more information. 


<Header for ‘Group ID registration', ID: "GRID"> 
Owner identifier <text string> $00 

Group symbol Shiok 

Group dependent data <binary data> 


4.28. Private frame 


This frame is used to contain information from a software producer that its program uses and does not fit into the 
other frames. The frame consists of an ‘Owner identifier’ string and the binary data. The 'Owner identifier’ is a null- 
terminated string with a URL containing an email address, or a link to a location where an email address can be 
found, that belongs to the organisation responsible for the frame. Questions regarding the frame should be sent to the 
indicated email address. The tag may contain more than one "PRIV" frame but only with different contents. It is 
recommended to keep the number of "PRIV" frames as low as possible. 


<Header for 'Private frame', ID: "PRIV"> 
Owner identifier <text string> $00 
The private data <binary data> 


5. The unsynchronisation scheme 


The only purpose of the 'unsynchronisation scheme’ is to make the ID3v2 tag as compatible as possible with existing 
software. There is no use in 'unsynchronising' tags if the file is only to be processed by new software. 
Unsynchronisation may only be made with MPEG 2 layer I, Il and Ill and MPEG 2.5 files. 


Whenever a false synchronisation is found within the tag, one zeroed byte is inserted after the first false 
synchronisation byte. The format of a correct sync that should be altered by ID3 encoders is as follows: 


SLILNIIIIL Wililssoses 


And should be replaced with: 
$11111111 00000000 111xxxxx 


This has the side effect that all $FF 00 combinations have to be altered, so they won't be affected by the decoding 
process. Therefore all the $FF 00 combinations have to be replaced with the $FF 00 00 combination during the 
unsynchronisation. 


To indicate usage of the unsynchronisation, the first bit in 'ID3 flags' should be set. This bit should only be set if the 
tag contains a, now corrected, false synchronisation. The bit should only be clear if the tag does not contain any false 
synchronisations. 


Do bear in mind, that if a compression scheme is used by the encoder, the unsynchronisation scheme should be 
applied *afterwards*. When decoding a compressed, 'unsynchronised' file, the 'unsynchronisation scheme' should be 
parsed first, decompression afterwards. 


If the last byte in the tag is $FF, and there is a need to eliminate false synchronisations in the tag, at least one byte of 
padding should be added. 


6. Copyright 
Copyright © Martin Nilsson 1998. All Rights Reserved. 


This document and translations of it may be copied and furnished to others, and derivative works that comment on or 
otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in 
part, without restriction of any kind, provided that a reference to this document is included on all such copies and 
derivative works. However, this document itself may not be modified in any way and reissued as the original 
document. 


The limited permissions granted above are perpetual and will not be revoked. 

This document and the information contained herein is provided on an "AS IS" basis and THE AUTHORS 
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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8. Appendix 


8.1. Appendix A - Genre List from ID3v1 
The following genres is defined in ID3v1 
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Dance 
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Hip-Hop 
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New Age 
Oldies 
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Pop 
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Rap 
Reggae 
Rock 
Techno 
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Soundtrack 


Euro-Techno 
. Ambient 
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2S), Oelvazaarlaibhaile 
30, IeSsyem 

31. Trance 

324 Clagsireeul 
33. Instrumental 
34. Acid 

35. House 

36. Game 

S75 S@wiaiwel Cllaye 
38. Gospel 

39. Noise 

40. AlternRock 
41. Bass 

LV apeercvolvula 

43. Punk 

44. Space 

45. Meditative 
46. Instrumental Pop 
47. Instrumental Rock 
AO Pielmeae 

49. Gothic 

50. Darkwave 


51. Techno-Industrial 
52. Electronic 

S35 Roles 

54. Eurodance 


55. Dream 
56. Southern Rock 


57. Comedy 
S86 Cubic 
59. Gangsta 
60. Top 40 


Cul Chita eecimnae 
62. Pop/Funk 

63. Jungle 

64. Native American 
65. Cabaret 

66. New Wave 

67. Psychadelic 

68. Rave 

69. Showtunes 


70. Trailer 
Tile Lox 
YZ, MWreavloyetil 


W385 M@cl Wiles 
Ya iWMesuel veya 
V5, Woilisa 

76. Retro 

Vie ivtoamer-ae 

18s ROCK & IR©ILIL 
WD, ilesecl Revell 


The following genres are Winamp extensions 


SO. ieilliz 


81. Folk-Rock 

B25 IWetesboimell Itoi 
83. Swing 

84. Fast Fusion 
85. Bebob 

SG, lehesin 

87. Revival 

88. Celtic 

89. Bluegrass 

90. Avantgarde 

Mil. Coie INocl< 
92. Progressive Rock 
93. Psychedelic Rock 
94. Symphonic Rock 
95. Slow Rock 

96. Big Band 

OF, Clhaereus 

98. Easy Listening 
OO, ACCUSES 
100. Humour 
101. Speech 
102. Chanson 
103. Opera 
104. Chamber Music 
105. Sonata 

106. Symphony 

107. Booty Bass 
108. Primus 

109. Porn Groove 
10. Satire 

Wil, Sule chkewa 

12, Cll 

sh, ALENAC iS) 

114. Samba 

15. Folklore 

G5 isyeiiLilevel 

117. Power Ballad 
Lil. Inlagrclomle Sere 
119. Freestyle 

120, Diese 

12, Pibliaie Reels 

122. ibiewia Sollo 

123. A cappella 
124. Euro-House 
125, iDevavers IslevILib 
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